1. Field of the Invention
The present invention relates generally to an improved data processing system, and in particular to a computer implemented method, data processing system, and computer program product for minimizing the message flow wait time for management user exits in a message broker application.
2. Description of the Related Art
Message (event) brokers are common middleware for large computer installations. Middleware is software that mediates between an application program and a network, managing the interaction between disparate applications across heterogeneous computing systems or platforms. These systems or platforms may be arranged in multiple layers, with an underlying system and multiple systems overlaying one another.
Message broker applications integrate existing software applications by typically providing mechanisms for connecting, routing, and transforming business data (messages) from a variety of transports without the need to change the underlying applications generating/consuming the data. Message flows are single threaded programs that process messages in a message broker. Message flows are considered the basic building blocks for message brokers. For example, FIG. 1 illustrates a typical web-based message broker application. In this example, two message flows in the message broker application are shown—one message flow (request message flow) 102 which processes a request to a back-end server, and another message flow (response message flow) 104 which processes the response to the request. Specifically, the request flow comprises hypertext transfer protocol input (HTTPInput 106) which generates message queue output (MQOutput 110) via a computation step, compute1 108. This MQOutput 110 is then provided to back-end server 112. The response flow 104 from back-end server 112 comprises a message queue input (MQInput 114) which generates HTTPReply 118 via a computation step, compute2 116.
A message broker application can dynamically load user exits. User exits comprise interfaces to a message broker application in which application developers may include additional management functionality, such as monitoring the performance of the message broker application. A user exit is invoked by a message broker application to provide the user defined management functionality in response to the occurrence of an event. Examples of events which trigger the invocation of a user exit in the message broker may include receiving a request, completing processing of the request, receiving the response, and completing processing of the response, among many others.
FIG. 2 illustrates how user exits may be invoked in various phases of message broker application 202. Web client 204 sends a request to back-end server 206 via message broker application 202, which generates request flow 208 and response flow 210. In this example, user exits may be invoked at location 1 212 when the request is received at message broker application 202, and at location 2 214 before and after the request is processed by message broker application 202. User exits may also be invoked at location 3 216 before and after the response is processed by message broker application 202, and at location 4 218 prior to the response being sent from message broker application 202 to web client 204.
Request and response flows are often executed in different execution threads in an asynchronous manner. Consequently, user exits in request/response message flows rely on the ability to pass data from the request message flow to the response message flow using a unique request identifier (ID), since one user exit does not know of the existence of the other user exits. Thus, when monitoring the progress of a request/response through a message broker application over multiple user exits, information obtained at one user exit may be accessed by another user exit further down the path by passing a request identifier between the message flows.
While conventional message broker applications allow information to be passed from a request message flow to the response message flow, conventional message broker applications employ algorithms which require a lock to be acquired on the global data map each time an item in the map is accessed. The wait time needed to process requests in these conventional message broker applications may result in a significant amount of overhead, since a response flow must wait to acquire a lock on the global data map before the response can be processed. In addition, when an item is added into or removed from a conventional global data map, the add/remove operation usually invalidates the iterators in the map. Iterators are objects which point to other objects in a container and are used to access those objects in turn. Iterators are typically used to iterate over a range of objects. If an iterator points to a certain item in the range, then adding/removing entries from the global data map can cause rearrangement of the existing iterators. Therefore, an original iterator can point to a different item after the rearrangement, and thus the iterators to the existing items in the map are no longer valid. Consequently, a read operation on the map to an existing item in the map cannot be performed using the invalidated iterators.